---
title: "DDD Naming"
date: 2023-05-07T02:39:29+03:00
description: "Naming в архитектуре"
tags: ["arch", "ddd", "naming"]
ShowToc: true
ShowBreadCrumbs: true
draft: false
---

На основе статьи [Делай нейминг как сеньор](https://habr.com/ru/companies/dododev/articles/714512/)

> Проще сменить имя в паспорте, чем исправить контракт, который имеет тысячи использований.

Выведем остальные следствия плохого нейминга:

1. требуется больше усилий → больше вероятность ошибки;
2. увеличивается энтропия → код сложнее поддерживать;
3. разработка идёт медленнее и труднее с нарастающим итогом.

> проблемы с неймингом → проблемы с пониманием предметной области.

Для перевода мы не пользуемся гугл-транслейтом. Наши инструменты:

- multitran.com для перевода,
- wooordhunt.ru для поиска английских терминов в контексте,
- context.reverso.net для поиска терминов по контексту.

Дополнительные советы, которые помогут сделать нейминг лучше

1. Явное > неявное. Отвлекитесь на секунду и представьте, что прошёл год. Пронеслась череда событий и вы снова вернулись к этому коду. Вспомните ли вы все нюансы, которые не отразили в названии? Представьте, что видите этот код в первый раз и что не выясняли с болью всякие мелкие особенности, которые могут скрываться за этой конструкцией. Например, переменная содержит время окончания всего цикла или только какой-то стадии цикла. Укажите это явно в обоих случаях. Сколько возможностей для багов можно посеять, если не уточнить и оставить загадку другому разработчику или даже самому себе!
2. Не стремитесь называть максимально коротко. Нейминг из 3-4 слов — это нормально. Передать конкретику одним словом, чаще всего, нельзя.
3. Одна переменная — одна цель. Например, вы хотите записать дату и время окончания смены и одновременно по этой же переменной понимать, закончилась ли смена. Никогда так не делайте! Только явное обозначение в другой булевой переменной. `ShiftEndedAt`, `IsShiftEnded`.
4. Отрицание только усложняет, а также это пример неявного поведения. Используйте явные наименования. Не «недоступно», а «доступ запрещён».
5. Вырабатывайте единую структуру. Например, используйте одинаковые суффиксы и префиксы: `Avg`, `Count`, `Percentage`, `Total`, `At`, `Name`,`unitName`, `productName`, `tripsDuration`, `couriersShiftsDuration`.
6. Используйте глаголы или прилагательные для уточнения контекста: `addedIngredients`, `removedIngredients`, `lateOrdersCount`.
7. Стандартизируйте нейминг для времени. Если система фиксирует какое-то событие, то используйте глагол в прошедшем времени + суффикс `At`: `happenedAt`, `startedAt`. Если по умолчанию храните время в UTC (что рекомендуется делать), а в контракте отдаёте локальное, то добавляйте ещё один суффикс `Local`: `happenedAtLocal`.
8. Опирайтесь на словари синонимов и значений.
